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Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage 
Abstract 


The Diameter base protocol specifies mechanisms whereby a given realm 
may advertise Diameter nodes and the supported transport protocol. 
However, these mechanisms do not reveal the Diameter applications 
that each node supports. A peer outside the realm would have to 
perform a Diameter capability exchange with every node until it 
discovers one that supports the required application. This document 
updates RFC 3588, "Diameter Base Protocol", and describes an 
improvement using an extended format for the Straightforward-Naming 
Authority Pointer (S-NAPTR) application service tag that allows for 
discovery of the supported applications without doing Diameter 
capability exchange beforehand. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6408. 


Jones, et al. Standards Track [Page 1] 


RFC 6408 Diameter S-NAPTR Usage November 2011 


Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 


to 


this document. Code Components extracted from this document must 


include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The Diameter base protocol [RFC3588] specifies three mechanisms for 
Diameter peer discovery. One of these involves the Diameter 
implementation performing a Naming Authority Pointer (NAPTR) query 
[RFC3403] for a server in a particular realm. These NAPTR records 
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provide a mapping from a domain to the DNS Service Locator (SRV) 
record [RFC2782] or A/AAAA record [RFC1035] [RFC3596] for contacting 
a server with the specific transport protocol in the NAPTR services 
field. 


The extended NAPTR usage for Diameter peer discovery defined by this 
document is based on the Straightforward-NAPTR (S-NAPTR) Dynamic 
Delegation Discovery System (DDDS) application defined in [RFC3958]. 
This document updates the Diameter peer discovery procedure described 
in Section 5.2 of [RFC3588] and defines S-NAPTR application service 
and application protocol tag values that permit the discovery of 
Diameter peers that support a specific Diameter application and 
transport protocol. 


2. Terminology 
The Diameter base protocol specification (Section 1.3 of [RFC3588]) 
and the Straightforward-NAPTR (S-NAPTR) DDDS application (Section 2.1 
of [RFC3958]) define the terminology used in this document. 

2.1. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 

3. Extended NAPTR Service Field Format 
The NAPTR service field format defined by the S-NAPTR DDDS 


application in [RFC3958] follows this Augmented Backus-Naur Form 
(ABNF) [RFC5234]: 


service-parms = [ [app-service] *(":" app-protocol) ] 
app-service = experimental-service / iana-registered-service 
app-protocol = experimental-protocol / iana-registered-protocol 
experimental-service = "x-" 1*30ALPHANUMSYM 
experimental-protocol = "x-" 1*30ALPHANUMSYM 
iana-registered-service = ALPHA *31ALPHANUMSYM 
iana-registered-protocol = ALPHA *31ALPHANUMSYM 

ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 

DIGIT = %x30-39 ; 0-9 

SYM = %x2B / %x2D / %x2E ; "4" / mem fmm 
ALPHANUMSYM = ALPHA / DIGIT / SYM 


; The app-service and app-protocol tags are limited to 32 
; characters and must start with an alphabetic character. 
; The service-parms are considered case-insensitive. 
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This specification refines the "iana-registered-service" tag 
definition for the discovery of Diameter agents supporting a specific 
Diameter application as defined below. 


iana-registered-service =/ aaa-service 

aaa-service "aaatap" appln-id 

appln-id 1*10DIGIT 
; Application Identifier expressed as 
; a decimal integer without leading 
; zeros. 


The appln-id element is the Application Identifier used to identify a 
specific Diameter application. The Diameter Application Identifier 
is a 32-bit unsigned integer, and values are allocated by IANA as 
defined in [RFC3588]. 


This specification also refines the "iana-registered-protocol" tag 
definition for the discovery of Diameter agents supporting a specific 
Diameter transport protocol as defined below. 


iana-registered-protocol =/ aaa-protocol 
aaa-protocol = "diameter." aaa-transport 
aaa-transport =."tep" 7 "“sctp™./ “Els. tep" 


The S-NAPTR application protocol tags defined by this specification 
MUST NOT be parsed in any way by the querying application or 


resolver. The delimiter (".") is present in the tag to improve 
readability and does not imply a structure or namespace of any kind. 
The choice of delimiter (".") for the application protocol tag 


follows the format of existing S-NAPTR application protocol tag 
registry entries, but this does not imply that it shares semantics 
with any other specifications that create registry entries with the 
same format. 


The S-NAPTR application service and application protocol tags defined 
by this specification are unrelated to the IANA "Service Name and 
Transport Protocol Port Number Registry" (see [RFC6335]). 


The maximum length of the NAPTR service field is 256 octets, 


including a one-octet length field (see Section 4.1 of [RFC3403] and 
Section 3.3 of [RFC1035]). 
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3.1. IETF Standards Track Diameter Applications 


A Diameter agent MUST be capable of using the extended S-NAPTR 
application service tag for dynamic discovery of a Diameter agent 
supporting Standards Track applications. Therefore, every IETF 
Standards Track Diameter application MUST be associated with a 
"aaa-service" tag formatted as defined in this specification and 
allocated in accordance with IANA policy (see Section 7). 


For example, a NAPTR service field value of: 
‘aaatap6:diameter.sctp’ 


means that the Diameter node in the SRV or A/AAAA record supports the 
Diameter Session Initiation Protocol (SIP) application (’6’) and the 
Stream Control Transmission Protocol (SCTP) as the transport 
protocol. 


3.2. Vendor-Specific Diameter Applications 


S-NAPTR application service and application protocol tag values can 
also be used to discover Diameter peers that support a vendor- 
specific Diameter application. In this case, the vendor-specific 
Diameter application MUST be associated with a "aaa-service" tag 
formatted as defined in this specification and allocated in 
accordance with IANA policy (see Section 7). 


For example, a NAPTR service field value of: 
‘aaatapl6777251:diameter.sctp’ 


means that the Diameter node in the SRV or A/AAAA record supports the 
Diameter Third Generation Partnership Project (3GPP) S6a application 
("16777251") and SCTP as the transport protocol. 


4. Backwards Compatibility 


Domain Name System (DNS) administrators SHOULD also provision legacy 
NAPTR records [RFC3403] in the RFC 3588 style in order to guarantee 
backwards compatibility with legacy Diameter peers that are RFC 3588 
compliant. If the DNS administrator provisions both extended S-NAPTR 
records as defined in this specification and legacy RFC 3588 NAPTR 
records, then the extended S-NAPTR records MUST have higher priority 
(e.g., lower order and/or preference values) than legacy NAPTR 
records. 
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3% 


Extended NAPTR-Based Diameter Peer Discovery 


The Diameter Peer Discovery principles are described in Section 5.2 
of [RFC3588]. This specification updates the NAPTR query procedure 
in the Diameter peer discovery mechanism by allowing the querying 
node to determine which applications are supported by resolved 
Diameter peers. 


The extended-format NAPTR records provide a mapping from a domain to 
the SRV record or A/AAAA record for contacting a server supporting a 
specific transport protocol and Diameter application. The resource 
record will contain an empty regular expression and a replacement 
value, which is the SRV record or the A/AAAA record for that 
particular transport protocol. 


The assumption for this mechanism to work is that the DNS 
administrator of the queried domain has first provisioned the DNS 
with extended-format NAPTR entries. The steps below replace the 
NAPTR query procedure steps in Section 5.2 of [RFC3588]. 


a. The Diameter implementation performs a NAPTR query for a server in 
a particular realm. The Diameter implementation has to know in 
advance in which realm to look for a Diameter agent, and in which 
Application Identifier it is interested. For example, the realm 
could be deduced from the Network Access Identifier (NAI) in the 
User-Name attribute-value pair (AVP) or extracted from the 
Destination-Realm AVP. 


b. If the returned NAPTR service fields contain entries formatted as 
"aaatapX:Y" where "X" indicates the Application Identifier and "Y" 
indicates the supported transport protocol(s), the target realm 
supports the extended format for NAPTR-based Diameter peer 
discovery defined in this document. 


If "X" contains the required Application Identifier and "y" 
matches a supported transport protocol, the Diameter 
implementation resolves the "replacement" field entry toa 
target host using the lookup method appropriate for the "flags" 
field. 


If "X" does not contain the required Application Identifier or 
"Y" does not match a supported transport protocol, the Diameter 
implementation abandons the peer discovery. 
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c. If the returned NAPTR service fields contain entries formatted as 
"aaatapX" where "X" indicates the Application Identifier, the 
target realm supports the extended format for NAPTR-based Diameter 
peer discovery defined in this document. 


If "X" contains the required Application Identifier, the 
Diameter implementation resolves the "replacement" field entry 
to a target host using the lookup method appropriate for the 
"flags" field and attempts to connect using all supported 
transport protocols following the order specified in 

Section 2.1 of [RFC3588]. 


If "X" does not contain the required Application Identifier, 
the Diameter implementation abandons the peer discovery. 


d. If the returned NAPTR service fields contain entries formatted as 
"aaa:X" where "X" indicates the supported transport protocol(s), 
the target realm supports Diameter but does not support the 
extended format for NAPTR-based Diameter peer discovery defined in 
this document. 


If "X" matches a supported transport protocol, the Diameter 
implementation resolves the "replacement" field entry toa 
target host using the lookup method appropriate for the "flags" 
field. 


e. If the returned NAPTR service fields contain entries formatted as 
"aaa", the target realm supports Diameter but does not support the 
extended format for NAPTR-based Diameter peer discovery defined in 
this document. The Diameter implementation resolves the 
"replacement" field entry to a target host using the lookup method 
appropriate for the "flags" field and attempts to connect using 
all supported transport protocols following the order specified in 
Section 2.1 of [RFC3588]. 


f. If the target realm does not support NAPTR-based Diameter peer 
discovery, the client proceeds with the next peer discovery 
mechanism described in Section 5.2 of [RFC3588]. 


5.1. Examples 
As an example, consider a client that wishes to discover a Diameter 
server in the exl.example.com realm that supports the Credit Control 


application. The client performs a NAPTR query for that domain, and 
the following NAPTR records are returned: 
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7 order pref flags service regexp replacement 

IN NAPTR 50 50 Se "aaa:diameter.sctp” "" 
_diameter._sctp.exl.example.com 

IN NAPTR 50 50 eo "aaatapl:diameter.sctp" "" 
_diameter._sctp.exl.example.com 

IN NAPTR 50 50 "Sy "aaatap4:diameter.sctp" ™" 


_diameter._sctp.exl.example.com 


This indicates that the server supports NASREQ (ID=1) and Credit 
Control (ID=4) applications over SCTP. If the client supports SCTP, 
it will be used, targeted to a host determined by an SRV lookup of 
_diameter._sctp.exl.example.com. 


That SRV lookup would return: 


oe Priority Weight Port Target 
IN SRV 0 1 3868 serverl.exl.example.com 
IN SRV 0 2 3868 server2.exl.example.com 


As an alternative example, a client wishes to discover a Diameter 
server in the ex2.example.com realm that supports the NASREQ 
application over SCTP. The client performs a NAPTR query for that 
domain, and the following NAPTR records are returned: 


Hee order pref flags service regexp replacement 

IN NAPTR 150 50 ma" "aaa:diameter.sctp" "" 
serverl.ex2.example.com 

IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" 
server2.ex2.example.com 

IN NAPTR 150 50 “an "aaatapl:diameter.sctp" "" 
serverl.ex2.example.com 

IN NAPTR 150 50 man "aaatapl:diameter.tls.tcp" "" 


server2.ex2.example.com 


This indicates that the server supports NASREQ (ID=1) over SCTP and 
Transport Layer Security (TLS)/TCP via hosts serverl.ex2.example.com 
and server2.ex2.example.com, respectively. 


Usage Guidelines 


Diameter is a peer-to-peer protocol, whereas most of the applications 
that extend the base protocol behave like client/server applications. 
The role of the peer is not advertised in the NAPTR tags and not even 
communicated during Diameter capability negotiation 
(Capabilities—Exchange-Request and Capabilities-—Exchange-Answer 
message exchange). For this reason, NAPTR-based Diameter peer 
discovery for an application defining client/server roles should only 
be used by a client to discover servers. 
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7. IANA Considerations 
7.1. IETF Diameter Application Service Tags 


IANA has reserved a value of "aaa" for Diameter in the "(S-NAPTR) 
Application Service Tag" registry created by [RFC3958]. IANA has 
also reserved the following S-NAPTR application service tags for 
existing IETF Diameter applications in the same registry. 


4---------------------------- + 
| Diameter Application | 

4------------------ 4---------------------------- + 
| 
| 
| 


| aaatapl NASREQ [RFC3588] 

| aaatap2 Mobile IPv4 [RFC4004] 

| aaatap3 Base Accounting [RFC3588] | 
aaatap4 Credit Control [RFC4006] 
aaatap5 EAP [RFC4072] 

| aaatap6 | SIP [RFC4740] 

| aaatap7 | Mobile IPv6 IKE [RFC5778] 

| aaatap8 | Mobile IPv6 Auth [RFC5778] | 

| aaatap9 | QoS [RFC5866] 

| aaatap4294967295 | Relay [RFC3588] | 

+------------------ +---------------------------- + 


Future IETF Diameter applications MUST reserve the S-NAPTR 
application service tag corresponding to the allocated Diameter 
Application ID as defined in Section 3. 


7.2. 3GPP Diameter Application Service Tags 
IANA has reserved the following S-NAPTR application service tags for 


existing 3GPP Diameter applications in the "S-NAPTR Application 
Service Tag" registry created by [RFC3958]. 


S SSR SSS = +S SSS SSS Se + 
| Tag | Diameter Application | 
Passes SSeS s E Sa am a a a A + 
| aaatap16777250 | 3GPP STa [TS29.273] | 
| aaatap16777251 | 3GPP S6a [TS29.272] | 
aaatapl16777264 3GPP SWm [TS29.273] 
aaatap16777267 | 3GPP S9 [TS29.215] 
4+---------------- Pls Sp SSSe SSS SSS SSS + 


Future 3GPP Diameter applications can reserve entries in the "S-NAPTR 
Application Service Tag" registry created by [RFC3958] that 
correspond to the allocated Diameter Application IDs as defined in 
Section 3. 
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IANA has reserved the following S-NAPTR application service tags for 
existing Worldwide Interoperability for Microwave Access (WiMAX) 

Forum Diameter applications in the "S-NAPTR Application Service Tag" 
registry created by [RFC3958]. 


aaatap16777281 


aaatap16777282 
aaat+ap16777283 
aaat+ap16777284 
aaatap16777285 
aaatap16777287 
aaat+ap16777288 


aaatap16777289 


| 
| 
| 
| 
| 
| 
| 
| aaatap16777286 
| 
| 
| 
| 
| 
| aaatap16777290 


+ 
| 
+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


+ 


Diameter Application 


WiMAX Network Access Authentication and 
Authorization Diameter Application (WNAAADA) 


[WiMAX-BASE] 


WiMAX Network Accounting Diameter Application 


(WNADA) [WiMAX-BASE] 


WiMAX MIP4 Diameter Application (WM4DA) 


[WiMAX-BASE] 


WiMAX MIP6 Diameter Application (WM6DA) 


[WiMAX-BASE] 


WiMAX DHCP Diameter Application (WDDA) 


[WiMAX-BASE] 


WiMAX Location Authentication Authorization 


Diameter Application (WLAADA) 


WiMAX Policy and Charging Control R3 Policies 
Diameter Application (WiMAX PCC-R3-P) 


[WiMAX-PCC] 


WiMAX Policy and Charging Control R3 Offline 


Charging Diameter Application 
[WiMAX-PCC] 


WiMAX Policy and Charging Control R3 Offline 
Charging Prime Diameter Application (WiMAX 


PCC-R3-OFC-PRIME) [WiMAX-PCC] 


WiMAX Policy and Charging Control R3 Online 


Charging Diameter Application 
[WiMAX-PCC] 


pe SE ee eae eS a ee ee JO, A ey ae go + 
| 
A aad ee a ma Ga "rae sed ie tei ca a es Fa et Sa el N + 
| 
| 
| 
| 
| 
| 
| 
| 
[WiMAX-LBS] 
| 
| 
| 
(WiMAX PCC-R3-OFC) | 
| 
| 
| 
(WiMAX PCC-R3-OC) 
‘ce eat ec Se: es, San eg ee Gat "Pa a i tt + 


Future WiMAX Forum Diameter applications can reserve entries in the 
"S-NAPTR Application Service Tag" registry created by [RFC3958] that 
correspond to the allocated Diameter Application IDs as defined in 


Section 3. 


7.4. Vendor-Specific Diameter Application Service Tags 


Vendor-Specific Diameter Application IDs are allocated by IANA 
according to the "First Come First Served" policy and do not require 
an IETF specification. However, the S-NAPTR application service tag 
registry created by [RFC3958] defines a registration policy of 
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7. 


Is 


"Specification Required" with a further stipulation that the 
"specification" is an RFC (of any category). If a vendor-specific 
Diameter application requires the functionality defined in this 
document, an RFC of any category MUST be published that reserves the 
S-NAPTR Application Service Tag corresponding to the Vendor-Specific 
Diameter Application ID as defined in Section 3. 


Diameter Application Protocol Tags 
IANA has reserved the following S-NAPTR Application Protocol Tags for 


the Diameter transport protocols in the "S-NAPTR Application Protocol 
Tag" registry created by [RFC3958]. 


+----------------—- +---------- + 
| Tag | Protocol | 
$------------------ +---------- + 
| diameter.tcp | TCP | 
| diameter.sctp | SCTP | 
| diameter.tls.tcp | TLS/TCP | 
+----------------—- +---------- + 


Future Diameter versions that introduce new transport protocols MUST 
reserve an appropriate S-NAPTR Application Protocol Tag in the 
"S-NAPTR Application Protocol Tag" registry created by [RFC3958]. 


Security Considerations 


This document specifies an enhancement to the NAPTR service field 
format defined in RFC 3588 and also modifications to the NAPTR 
processing logic defined in RFC 3588. The enhancement and 
modifications are based on the S-NAPTR, which is actually a 
simplification of the NAPTR, and therefore the same security 
considerations described in RFC 3588 [RFC3588] are applicable to this 
document. No further extensions are required beyond the security 
mechanisms offered by RFC 3588. However, a malicious host doing 
S-NAPTR queries learns applications supported by Diameter agents ina 
certain realm faster, which might help the malicious host to scan 
potential targets for an attack more efficiently when some 
applications have known vulnerabilities. 
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